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RADIUS Option for the DHCPv6 Relay Agent 
Abstract 


The DHCPv6 RADIUS option provides a mechanism to exchange 
authorization and identification information between the DHCPv6é relay 
agent and DHCPv6 server. This architecture assumes that the Network 
Access Server (NAS) acts as both a DHCPv6 relay agent and RADIUS 
client. When receiving messages from the DHCPv6 clients, the NAS 
consults the RADIUS server and adds the RADIUS response when 
forwarding the DHCPv6 client’s messages to the DHCPv6 server. The 
DHCPv6 server then uses that additional information to generate an 
appropriate response to the DHCPv6 client’s requests. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http: //www.rfc-editor.org/info/rfc7037. 
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1. Introduction 


DHCPv6 provides a mechanism that allows the server to assign or 
delegate both stateful and stateless configuration parameters to 
clients. The stateful configuration parameters include IPv6 
addresses [RFC3315] and IPv6 prefixes [RFC3633]. The stateless 
configuration parameters [RFC3736] include, for example, DNS 
[RFC3646], or a Fully Qualified Domain Name (FQDN) of an Address 
Family Transition Router (AFTR) [RFC6334]. In the scenarios 
described in this document, the DHCPv6 server is deployed in the 
central part of an ISP network. 


RADIUS [RFC2865] is widely used as the centralized authentication, 
authorization, and user management mechanism for service provision in 
a Broadband access network. [RFC3162], [RFC4818], [RFC6519], and 
[RFC6911] specify the attributes that support the service provision 


Yeh & Boucadair Standards Track [Page 2] 


RFC 7037 DHCPv6 RADIUS Option October 2013 


for IPvé-only and IPv6-transition access. The RADIUS server 
authorizes the Network Access Server (NAS) to assign an IPv6 address 
or prefix from the indicated pool, or to assign an IPv6 address or 
prefix with an explicitly indicated value, and to indicate other 
configuration parameters as per the RADIUS attributes for the 
subscribers. 


When the NAS acts as the distributed DHCPv6 server and RADIUS client 
simultaneously, it communicates with the RADIUS server after 
receiving a request from the DHCPv6 client. Upon receiving the 
Access-Accept message from the RADIUS server, the NAS then responds 
to the DHCPv6 client’s requests per the associated authorization 
information indicated by the RADIUS attributes in the Access-—Accept 
message. When NAS acts as the DHCPv6 relay agent and RADIUS client 
simultaneously, and the centralized DHCPv6 server is co-located with 
the RADIUS server, they may share the same database of users. 
However, when the centralized DHCPv6 server is not located in the 
same place as the RADIUS server, a new communication mechanism is 
needed for the DHCPv6 relay agent to transfer the authorization 
information indicated by the RADIUS attributes to the DHCPv6 server. 


2. Terminology and Language 


This document specifies a new DHCPv6 option for the DHCPv6 Relay 
Agent to transfer the authorization information of RADIUS attributes 
received in the Access-Accept message from the RADIUS server to the 
centralized DHCPv6é server. Definitions for terms and acronyms not 
specified in this document are defined in [RFC2865] and [RFC3315]. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Network Scenarios 


Figures 1 and 2 show the typical network scenarios where the 
communication mechanism introduced in this document is necessary. In 
these scenarios, the centralized DHCPv6 server is not co-located with 
the RADIUS server, but both are in the same administrative domain. 
The NAS acts as the DHCPv6 relay agent and the RADIUS client 
simultaneously. Figure 1 shows the sequence of DHCPv6é and RADIUS 
messages for the IP over Ethernet (IPOE) access model, when the 
access loop adopts the direct Ethernet encapsulation. Figure 2 shows 
the sequence of DHCPv6 and RADIUS messages for the PPP over Ethernet 
(PPPoE) access model. 
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The mechanism introduced in this document is a generic mechanism and 
might also be employed in other network scenarios where the DHCPv6 
relay agent and the RADIUS client are located in the same device. 


|DHCPv6 | Access Model: | Nas | [RADIUS | 
[Client | IPOE | | |Server | 


| 
| 
| ---Access-Request---------- >| 
| 


| <--Access-Accept------------ | 
(e.g. Delegated-IPv6-Prefix) 


(OPTION_RADIUS) 


<->Relay-replysssHsSssesS-5 


DHCPv6 messages RADIUS messages 

prenia + 
DHCPv6 
Server 
+------— + 

| | | 

| | ---Relay-forward----------- >| 

| | (OPTION_RADIUS) | 

| <--Relay-reply ------------- | 

| <--Advertise--------------- | 

| (e.g., IA_PD) | 

| ---Request---------------- > | 

| (e.g., IA_PD) ---Relay-forward----------- > 

| 

| 

| 

| 

| 


DHCPv6 messages DHCPv6 messages 


Figure 1: Network Scenario and Message Sequence When Employing DHCPv6 
RADIUS Option in IPOE Access 
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+------- + +------- + +------- + 
|DHCPv6 | Access Model: | NAS | [RADIUS | 
[Client | PPPOE | | | Server | 
+------- + +------- + +------- + 

RADIUS Client/DHCPv6 Relay Agent 
| | | 
|--PPP LCP Config-Request-——> | 
==5Access=-Request—---==s5== > 
| |<--Access-Accept------------ | 
|<----PPP LCP Config-ACK----| (e.g. Delegated-IPv6-Prefix) | 


PPP messages RADIUS messages 


+------- + 
|DHCPv6 | 
|Server | 
+-------— + 

| | | 

S=“SOICltHS5===4$5=425=== > 

| —=-Rélay=forward=sss-Ss-ss> > 

| | (OPTION_RADIUS) | 

| | | 

| |<--Relay-reply ------------- | 

|<--Advertise--------------- | | 

| (e.g., IA_PD) | | 

| ---Request---------------- >| | 

| (e.g., IA_PD) | ---Relay-forward----------- >| 

| | (OPTION_RADIUS) 

| | | 

<=-Relay reply a -Hasa-sasse- 
<=—Réeplyss==45- 2S SSeS 
| (e.g., IA_PD) | | 


Figure 2: 


If the authentication or the authorization through RADIUS fails, 
associated message sequences will stop. 


DHCPv6 messages DHCPv6 messages 


Network Scenario and Message Sequence When Employing DHCPv6 
RADIUS Option in PPPoE Access 


the 
The NAS acting as the DHCPv6 


relay agent will not forward the message received from the client to 


the DHCPv6 server. 
through RADIUS passes, 
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If the authentication or the authorization 
the NAS MUST store the information indicated 
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in the RADIUS attributes received in the Access-Accept message from 
the RADIUS server during the whole session. How the NAS manages this 
information during the RADIUS session is out of the scope of this 
document. 


After receiving a RENEW (5) message from the DHCPv6 client, the NAS 
SHOULD NOT initiate a new Access-Request/Access-Accept message 
exchange with the RADIUS server. After receiving a REBIND (6) 
message from the DHCPv6 client, the NAS MUST initiate a new Access- 
Request/Access-Accept message exchange with the RADIUS server, unless 
RADIUS capability is disabled on the NAS. 


4. DHCPv6é RADIUS Option 


The OPTION_RADIUS is a DHCPv6 option used by the DHCPv6 relay agent 
to carry the authorization information of RADIUS attributes received 
in the Access-Accept message from the RADIUS server. 


The format of the OPTION_RADIUS option is defined as follows: 


0 1 2 E 

0 IT-2 345g 7 89 0 123A 5e 78 9-0 12 3A G T7 89-0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++HHH 
| OPTION_RADIUS | option-len | 
toto tatatata—tatata tata tata tata ta tata tatatatatatatatattatatatat-t 
| option-data (List of RADIUS Attributes) 

Fat ota tata taotatatatao tata tata ta ta tata tatatatatatatatatatatatat—t-t 


opt ion-code 81 
option-len Length of the option-data in octets 
option-data List of one or more RADIUS attributes 


The option-data of OPTION_RADIUS is a list of one or more RADIUS 
attributes received in the Access-Accept message from the RADIUS 
server. The format of RADIUS attributes is defined in Section 5 of 
[RFC2865] as well as Sections 2.1 and 2.2 of [RFC6929]. If multiple 
attributes with the same type (including the Long Extended Type 
defined in Section 2.2 of [RFC6929]) are present, the order of 
attributes with the same type MUST be the same as that received from 
the RADIUS server. The OPTION_RADIUS can only contain the RADIUS 
attributes listed in the "RADIUS Attributes Permitted in DHCPv6 
RADIUS Option" registry. 
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According to the network scenarios described in Section 3, the 
OPTION_RADIUS should appear in the RELAY-FORW (12) message relaying 
SOLICIT (1), REQUEST (3), and REBIND (6) from the DHCPv6 client and 
may appear in the RELAY-FORW (12) relaying any other message from the 
DHCPv6 client. 


4.1. RADIUS Attributes Permitted in DHCPv6 RADIUS Option 


The RADIUS attributes listed in the following table are the initial 
attributes registered in the "RADIUS Attributes Permitted in DHCPv6 
RADIUS Option" registry. New RADIUS attributes can be added to this 
list after Expert Review [RFC5226]. 


Type Code Attribute Reference 
26 Vendor-Specific [RFC2865] 
123 Delegated-IPv6-Prefix [RFC4818] 
144 DS-Lite-Tunnel-Name [RFC6519] 
168 Framed-IPv6—Address [RFC6911] 
169 DNS-Server-IPv6-Address [RFC6911] 
171 Delegated-IPv6—-Prefix-Pool [RFC6911] 
172 Stateful-IPv6-Address-Pool [RFC6911] 


Note: The RADIUS attribute’s ’Length’ defined in Section 5 of 
[RFC2865] includes the length of '/Type’ and ‘Length’ fields. 


5. DHCPv6é Relay Agent Behavior 


If the Relay Agent is configured to send OPTION_RADIUS, and the 
Access-Accept message from the RADIUS server contained RADIUS 
attributes permitted for use in OPTION_RADIUS, the Relay Agent MUST 
include OPTION_RADIUS in the RELAY-FORW (12) message. The DHCPv6 
relay agent adds the permitted RADIUS attributes into OPTION_RADIUS 
one by one; if multiple attributes with the same type are present, 
the order of attributes with the same type MUST be the same as that 
received from the RADIUS server. 


6. DHCPv6 Server Behavior 


Upon receipt of the RELAY-FORW (12) message with OPTION_RADIUS from a 
relay agent, the DHCPv6 server that supports OPTION_RADIUS SHOULD 
extract and interpret the RADIUS attributes in the OPTION_RADIUS and 
use that information to select configuration parameters for the 
requesting client. If the DHCPv6 server does not support 
OPTION_RADIUS, the DHCPv6 server MUST silently discard this option. 


Yeh & Boucadair Standards Track [Page 7] 


RFC 7037 DHCPv6 RADIUS Option October 2013 


7. DHCPv6é Client Behavior 


OPTION_RADIUS is only exchanged between the relay agents and the 
servers. DHCPv6 clients are not aware of the usage of OPTION_RADIUS. 
DHCPv6 clients MUST NOT send OPTION_RADIUS and MUST ignore 
OPTION_RADIUS if received. 


8. Security Considerations 


Known security vulnerabilities of the DHCPv6é and RADIUS protocols may 
apply to their options. Security issues related with DHCPv6 are 
described in Section 23 of [RFC3315]. Security issues related with 
RADIUS are described in Section 8 of [RFC2865], Section 5 of 
[RFC3162], and Section 11 of [RFC6929]. 


The mechanism described in this document may introduce a new attack 
vector against the DHCPv6 server in cases where the DHCPv6 relay 
agent is compromised. By forging the RADIUS attributes contained in 
the OPTION_RADIUS of the RELAY-FORW (12) messages, the attacker may 
influence the parameter assignment on the DHCPv6é server for the 
DHCPv6 clients. However, as described in the Section 3, NAS always 
belongs to the same administrative domain of the DHCPv6 server in the 
real deployment. 


Network administrators should be aware that although RADIUS messages 
are encrypted, DHCPv6 messages are always unencrypted. It is 
possible that some RADIUS vendor-specific attributes might contain 
sensitive or confidential information. Network administrators are 
strongly advised to prevent such information from being included in 
DHCPv6 messages. 


If the use of vendor-specific attributes with confidential content is 
required, administrators are advised to use IPsec with encryption to 
protect the confidentiality of the RADIUS attributes. Relay agents 
and servers implementing this specification MUST support the use of 
IPsec Encapsulating Security Payload (ESP) with encryption in 
transport mode, according to Section 3.1.1 of [RFC4303] and 

Section 21.1 of [RFC3315]. 


9. IANA Considerations 


IANA has assigned OPTION_RADIUS (81) in the "DHCP Option Codes" 
registry, as defined in Section 4. In addition, IANA has created a 
new registry entitled "RADIUS Attributes Permitted in DHCPv6é RADIUS 
Option" in the "Dynamic Host Configuration Protocol for IPv6 
(DHCPv6)" registry, as defined in Section 4.1. The new registry 
enumerates the RADIUS Attributes Types 
(http://www.iana.org/assignments/radius-types) that are permitted for 
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inclusion in the DHCPv6 RADIUS option. The allocation policy of this 
"RADIUS Attributes Permitted in DHCPv6é RADIUS Option" registry is 
Expert Review per [RFC5226]. Designated experts should carefully 
consider the security implications of allowing the relay agent to 
include new RADIUS attributes to this registry. 
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